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Abstract 

The  current  military  environment  means  the  U.S.  Army  needs  the  capabil¬ 
ity  to  strategically  site  contingency  bases  (CBs)  for  rapid  response 
throughout  a  joint  area  of  operations.  To  help  with  this  need,  the  Army  is 
funding  work  in  the  Engineering  Site  Identification  for  the  Tactical  Envi¬ 
ronment  (ENSITE)  program,  which  develops  data  and  knowledge  capabili¬ 
ties  to  assist  decisions  for  CB  site  locations.  Critical  to  the  ENSITE 
program  is  the  capability  to  integrate  geospatial  data  elements  in  ways  that 
broaden  and  improve  military  planners’  understanding  of  the  operating 
environment.  To  address  this  concern,  ENSITE  HUB  is  the  set  of  tools  de¬ 
veloped  for  collecting,  processing,  and  storing  the  various  geospatial  data 
required  to  execute  ENSITE’s  analytical  tools.  The  end  product  of  the 
ENSITE  HUB  workflow  is  a  mission  folder,  which  is  a  transportable  folder 
following  a  consistent  structure.  This  report  provides  a  temporal  snapshot 
of  the  ENSITE  HUB  software  and  process. 


DISCLAIMER:  The  contents  of  this  report  are  not  to  be  used  for  advertising,  publication,  or  promotional  purposes.  Ci¬ 
tation  of  trade  names  does  not  constitute  an  official  endorsement  or  approval  of  the  use  of  such  commercial  products. 
All  product  names  and  trademarks  cited  are  the  property  of  their  respective  owners.  The  findings  of  this  report  are  not  to 
be  construed  as  an  official  Department  of  the  Army  position  unless  so  designated  by  other  authorized  documents. 

DESTROY  THIS  REPORT  WHEN  NO  LONGER  NEEDED.  DO  NOT  RETURN  IT  TO  THE  ORIGINATOR. 
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1  Introduction 

1.1  Background 

The  Engineer  Site  Identification  for  the  Tactical  Environment  (ENSITE) 
program  is  dedicated  to  empowering  military  planners  with  the  data  and 
knowledge  for  siting  contingency  base  (CB)  locations.  The  program  is 
sponsored  by  the  Assistant  Secretary  of  the  Army  for  Acquisition,  Logis¬ 
tics,  and  Technology  (ASA(ALT))  with  a  funding  timeline  of  October  2015 
to  September  2018.  Figure  1  depicts  the  areas  of  research  for  the  ENSITE 
research  program. 

CB  locations  and  designs  are  not  one-size-fits-all;  rather,  they  should  be 
viewed  as  a  multilayer  decision  process  to  support  the  mission  and  com¬ 
mander’s  intent.  The  built,  ecological,  and  sociocultural  environments  im¬ 
pact  military  bases  and,  in  turn,  bases  affect  those  environments.  Failure 
to  understand  these  effects  may  result  in  increased  logistical  burdens  and 
unintended  consequences  on  local  populations  and  natural  resources— 
negatively  impacting  the  military  mission. 


Figure  1.  Overview  of  environments  that  are  visualized  and  integrated  as  part 

of  the  ENSITE  process. 
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ENSITE  provides  military  planners  with  the  ability  to  integrate  and  visual¬ 
ize  data  of  the  built,  natural,  and  social  environments  to  support  site  anal¬ 
ysis.  ENSITE  builds  upon  leading  geospatial  platforms  already  in  use  by 
the  Army  (including  ESRI  ArcMap®)  to  offer  an  easy-to-use,  customized 
set  of  workflows  that  remotely  evaluates  the  built,  natural,  and  social  envi¬ 
ronment  characteristics  of  a  location  in  support  of  siting  CBs.  ENSITE 
combines  Army  doctrine,  open-source  data,  and  authoritative  Army  data 
in  conjunction  with  user  input  to  execute  automated  processes  capable  of 
processing  large  amounts  of  data  in  a  rapid,  consistent,  and  standardized 
manner. 

With  such  a  tool,  CB  planners  (as  well  as  designers,  operators,  and  manag¬ 
ers)  can  rapidly  assess  possible  current  and  future  situations  to  provide 
proactive  operational  control  and  timely  alternative  situational  analyses 
while  they  are  deployed  or  as  part  of  their  training  programs. 

ENSITE’s  software  capability  supports  the  full  life  cycle  of  the  base— from 
design,  construction,  and  operations/management,  to  deconstruction— 
with  software  components  that  add  specific  functions  and  features  while 
minimizing  complexity  for  the  end  user.  ENSITE  is  constructed  as  a  collec¬ 
tion  of  software  components  (“plug-ins”)  developed  to  answer  the  follow¬ 
ing  questions: 

•  What  resources  and  infrastructure  are  locally  available? 

•  Are  operations  likely  to  affect  the  life  patterns  of  the  local  population? 

•  Where  will  the  construction  of  a  base  camp  best  leverage  local  re¬ 
sources  and  minimize  social  impacts? 

•  How  do  we  build  a  base  camp  for  a  specific  intent  as  well  as  for  a  sus¬ 
tainable  lifecycle? 

1.2  Objective 

This  report  outlines  the  general  resources,  data  standards,  and  file  struc¬ 
tures  that  make  up  the  process  by  which  data  is  collected,  managed,  and 
utilized  in  the  ENSITE  software,  particularly  through  the  semi-automated 
data  collection  process  referred  to  as  ENSITE  HUB. 

1.3  Approach 

Within  this  report,  Chapter  2  provides  an  overview  of  the  data  architec¬ 
ture.  It  defines  the  data  standards  and  describes  how  data  is  collected, 
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stored,  and  utilized  via  a  workflow  chart.  Chapter  3  details  ENSITE  HUB, 
ENSITE’s  semi-automated  data  collection  process  that  gathers  geospatial 
data  from  various  sources  and  processes  them  so  that  they  can  be  ingested 
by  ENSITE.  Chapter  3  provides  detailed  execution  instructions  for 
ENSITE  HUB.  Chapter  4  concludes  with  discussion  of  future  improve¬ 
ments. 

1.4  Scope 

This  report  is  noted  as  version  1.0  because  it  was  completed  at  the  midway 
point  in  the  ENSITE  development  effort.  It  is  anticipated  that  provisions 
within  this  report  will  be  updated  as  the  Army’s  needs  and  the  ENSITE 
program  evolve.  Thus,  additional  updates  of  this  report  (version  2.0,  etc.) 
are  anticipated. 
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2  Data  Architecture 

A  data  architecture  creates  a  common  operating  environment  for  software 
by  setting  data  standards  and  describing  how  data  is  collected,  stored,  and 
utilized.  The  Army  recognizes  that  the  collection,  management,  and  analy¬ 
sis  of  data  has  significant  effects  on  mission  effectiveness.  The  Army  and 
the  National  Geospatial-Intelligence  Agency  (NGA)*  work  together  to  de¬ 
velop  and  maintain  databases  that  support  Army  Geospatial  Information 
and  Services  (GI&S).  Army  geospatial  units  and  activities  develop  their  ge¬ 
ospatial  databases  in  accordance  with  the  Ground-Warfighter  Geospatial 
Data  Model  (GGDM)  standards.  The  Army  Geospatial  Enterprise  (AGE)  is 
where  the  standardized  geospatial  information  is  collected,  managed,  ana¬ 
lyzed,  visualized,  and  disseminated  across  the  Army.  The  “AGE  is  a  distrib¬ 
uted  SSGF  [Standard  Sharable  Geospatial  Foundation]  database  and 
supporting  infrastructure  that  is  based  on  a  common  suite  of  interoperable 
software”  (Army  Technique  Publication  [ATP]  3-34-80).  ENSITE  abides 
by  the  AGE  SSGF  in  support  of  the  Army’s  Common  Operational  Picture. 

2.1  Data  standards 

ENSITE  synchronizes  with  the  Army’s  geospatial  data  standard— GGDM. 
GGDM  was  developed  from  the  National  System  for  Geospatial-Intelli¬ 
gence  (NSG),  a  comprehensive  framework  developed  by  NGA.  The  GGDM 
schema  comprises  elements  of  the  NSG  relating  specifically  to  ground 
warfighting;  for  example  elements  related  to  ocean  navigation  are  ex¬ 
cluded.  The  GGDM  helps  to  eliminate  stovepipes,  reduce  costs,  simplify 
acquisition  and  accelerate  transition  of  technology  as  part  of  a  SSGF.  The 
data  model  is  the  ground-warfighter  "container"  into  which  geospatial 
data  elements  are  collected,  managed  and  used  for  analysis.  It  provides  a 
mechanism  for  storing  and  sharing  ground-warfighter  specific  feature  data 
across  multinational  ground  forces. 

A  roadmap  is  underway  for  transitioning  Army  ground-warfighter  systems 
and  geospatial  data  to  the  GGDM.  U.S.  Army  Geospatial  Center  (AGC), 
Distributed  Common  Ground  System- Army  (DCGS-A),  and  other  Army 


*  NGA  is  the  lead  federal  agency  for  geospatial  intelligence  (GEOINT)  and  manages  a  global  consortium 
of  more  than  400  commercial  and  government  relationships.  NGA  is  a  unique  combination  of  intelli¬ 
gence  agency  and  combat  support  agency.  It  is  the  world  leader  in  timely,  relevant,  accurate  and  ac¬ 
tionable  GEOINT.  (www.nga.mil/About/) 
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and  U.S.  Marine  Corps  (USMC)  geospatial  datasets  and  systems  are  transi¬ 
tioning  to  the  GGDM.  Future  versions  of  the  GGDM  may  include  addi¬ 
tional  ground  forces  enterprise  content  that  include  high-resolution  urban 
information,  additional  aeronautical  information,  modeling  and  simula¬ 
tion,  tactical  information,  and  updates  based  on  common  geospatial  data 
requirements  across  ground  force  components. 

Geospatial  data  is  the  foundation  for  the  U.S.  Army  Acquisition  Support 
Center’s  (USAASC)*  Common  Operating  Picture  (COP).  The  establishment 
of  a  common  vocabulary  enables  consistent  management  and  sharing  of 
feature  data  generated  by  national  agencies,  army,  and  other  services  or¬ 
ganizations.  The  U.S.  Army  Corps  of  Engineers'  AGC  is  the  focal  point  for 
the  AGE.  AGC  is  responsible  for  providing  the  standards  and  technology  to 
acquire,  manage,  and  share  geospatial  data  for  the  warfighter. 

2.1.1  Naming  conventions 

GGDM  dictates  naming  conventions  for  naming  geospatial  data  to  allow 
useful  information  to  be  deduced  from  the  names  based  on  regularities. 

2. 1.1.1  Vector  data 

Vector  data  located  within  ENSITE’s  GGDM-compliant  database  will  con¬ 
form  to  the  GGDM  schema.  This  schema  includes  both  the  names  for  fea¬ 
ture  classes  and  the  possible  field  values.  For  vector  datasets  which  fall 
outside  the  scope  of  GGDM  (i.e.,  networked  datasets,  spatial  nodes  of  at¬ 
traction,  or  space  syntax),  the  following  standards  are  used  (adapted  from 
Boone  County  2008). 

•  Title  Case  is  preferred  for  readability. 

•  No  special  characters  are  permitted  with  the  exception  of  underscore 
(_)• 

•  The  number  of  characters  comprising  a  Feature  Class  name  is  unlim¬ 
ited;  however,  brevity  is  preferred. 

•  Names  should  be  in  stated  in  singular  form,  rather  than  plural. 


*  USAASC  supports  the  program  executive  offices  in  the  areas  of  human  resources,  resource  manage¬ 
ment  (manpower  and  budget),  program  structure,  and  acquisition  information  management. 
(http://asc.army.mil/web/organization) 
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•  Static  feature  classes  with  a  yearly  vintage  must  indicate  the  compila¬ 
tion  circa  as  a  4-digit  suffix  to  the  feature  class  name  (e.g.,  ZoningPer- 
mitsi990). 

•  Static  feature  classes  with  a  monthly  compilation  period  must  have  a 
suffix  consisting  of  a  4-digit  year  followed  consecutively  by  a  2-digit 
month  (e.g.,  ZoningPermitsi99903). 

2. 1.1.2  Raster  data 

Because  of  the  variety  of  scales  and  specifics  of  rasters,  there  is  not  a  gen¬ 
eral  standard  for  naming  rasters.  The  NSG  Application  Schema  (NAS) 
does  not  outline  conventions  for  rasters  nor  does  the  Department  of  De¬ 
fense  (DoD)-sponsored  Spatial  Data  Standards  for  Facilities,  Infrastruc¬ 
ture,  and  Environment  (SDSFIE).  The  SDSFIE  website,  however,  provides 
a  set  of  “in-progress”  best  practices  for  all  forms  of  raster  data  (imagery, 
elevation,  etc.),  and  contains  a  compendium  of  raster  and  related  stand¬ 
ards  that  are  considered  most  applicable  for  Installation  Geospatial  Infor¬ 
mation  and  Services  (IGI&S).* 

Following  these  best  practices,  ENSITE’s  convention  for  naming  rasters  is 
to  preserve  their  name  from  the  original  source.  For  example,  one  of 
ENSITE’s  basemap  layers  is  a  digital  elevation  model  (DEM).  This  is  ac¬ 
quired  from  AGC’s  Common  Map  Background  (CMB),  with  the  filename 
“CMB_ELV_SRTM2”  so  ENSITE’s  DEM  uses  that  name.  ENSITE’s  stake¬ 
holder  engagement  with  Army’s  Geospatial  Planning  Cells  (GPCs)  indi¬ 
cates  that  geospatial  users  are  often  familiar  with  source  names. 
Additionally,  preserving  these  names  makes  tracking  source  data  and 
metadata  easier.  One  limitation  of  this  is  that  ESRI  geodatabases  do  sup¬ 
port  names  longer  than  13  characters  for  raster’s  stored  as  an  ESRI  grid; 
therefore,  some  names  may  be  truncated. 

2.1.2  Metadata 

Metadata  provides  information  about  data  and  is  an  essential  component 
of  documenting  geospatial  data.  As  part  of  the  data  governance  and  review 
process,  metadata  is  established  for  each  data  source.  All  data  must  follow 


*  https://www.sdsfieonline.org/Standards/Raster 
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a  specific  template  and  answer  specific  questions  about  data  source,  limi¬ 
tations,  and  justifications  for  inclusions.  Examples  of  metadata  for 
ENSITE  can  be  found  in  Section  2.6,  “Input  data.” 

2.2  Data  structure 

In  the  endeavor  to  be  flexible  and  light,  ENSITE  users  must  configure  the 
software  for  their  area  of  interest  and  mission.  In  other  words,  global  data 
does  not  come  pre-loaded.  Users  must  load  their  own  data.  That  data  is 
structured  and  managed  in  a  way  that  it  is  interoperable  and  scalable.  So 
once  data  has  been  established  for  an  area  of  interest,  it  is  shareable  and 
its  outputs  are  also  sharable/merge-able  (i.e.,  SSGF). 

Figure  2  provides  a  graphic  representation  of  the  ENSITE  data  structure 
and  workflow.  As  shown,  data  feeds  a  geodatabase  that  analytical  applica¬ 
tions  (i.e.,  plug-ins)  draw  from.  The  ENSITE  user  accesses  a  user-interface 
to  run  and  visualize  analyses.  Outputs  can  be  saved  to  the  internal  geoda¬ 
tabase.  The  data/geodatabase  is  housed  in  what  is  referred  to  as  the  Mis¬ 
sion  Folder.  The  Mission  Folder  contains  data  for  a  specific  area  of 
interest.  A  user,  for  example,  may  create  a  Mission  Folder  for  Dhaka, 
Bangladesh  and  another  for  Manila,  The  Philippines.  The  analytical  appli¬ 
cations  are  universal.  The  applications  are  discrete  packages  of  code  that 
run  consistently  on  any  Mission  Folder  geodatabase.  The  challenge  is  that 
not  all  data  that  is  needed  to  run  the  analytical  applications  are  organized 
according  to  GGDM  standards.  ENSITE  HUB  is  a  semi-automated  conver¬ 
sion  process.  Users  acquire  the  necessary  data  and  then  run  it  through 
ENSITE  HUB’s  tools  and  populate  the  Mission  Folder  with  the  data.  Thus, 
analysis  input  data  is  most  commonly  generated  through  ENSITE  HUB. 
Supporting  data  is  often  preloaded  or  obtainable  from  ENSITE  managers. 
Analysis  output  data  is  generated  from  running  specific  analytical  applica¬ 
tions  to  the  input  data. 
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Figure  2.  ENSITE  data  model  for  structure  and  workflow. 
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2.3  The  Mission  Folder 

The  format  of  the  Mission  Folder  structure  is  fixed  to  allow  for  consistent 
development  across  mission  areas.  The  Mission  Folder  segregates  data 
based  on  type.  This  is  because  GGDM  is  a  vector  standard,  and  the  data¬ 
base  must  be  modified  to  include  raster  data.  The  root  of  the  Mission 
Folder  contains  three  components  that  hold  the  inputs  to  ENSITE:  (l) 
“Data  HUB”  to  contain  the  ENSITE  HUB  outputs/ analysis  input  data;  (2) 
“Studies”  to  contain  analysis  outputs;  and  (3)  “Supporting”  to  contain 
basemap  features.  Figure  3  provides  a  screenshot  of  the  Mission  Folder  for 
an  area  of  interest  (AOI)  named  McCoy. 

Figure  3.  Screenshot  of  the  Mission  Folder  and  subfolders 
for  an  AOI  named  McCoy2. 

E)  S  McCoy2 
E  S  DataHUB 

E  ij  RASTER.gdb 
S  3  Vector.gdb 
B  ij  HUB_Analysis,gdb 
E  IJI  HUB_Scratch.gdb 
S  Studies 
El  Q  Supporting 

B  Q  Analysis_Support 
E  B  Basemap 
E  B  Imagrey 
El  B  Supporting 
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2.3.1  The  Data  Hub  Folder 

The  Data  Hub  Folder  contains  both  intermediate  data  (held  in 
scratch. gdb)  and  analyses  that  will  eventually  feed  into  ENSITE.  There  are 
four  geodatabases  in  the  folder:  ENSITE_RASTER,  ENSITE_VECTOR, 
HUB_Scratch.gdb,  and  HUB_Analysis 

1.  ENSITE_RASTER  is  a  geodatabase  that  contains  raster  data.  Raster 
data  currently  used  in  ENSITE  are  all  available  from  the  AGC’s  CMB, 
and  the  current  structure  in  ENSITE  preserves  the  naming  conventions 
used  in  CMB. 

2.  ENSITE_VECTOR  is  a  geodatabase  that  holds  the  vector  data  in  a 
GGDM-compliant  format.  The  database  contains  all  of  the  data  in  a 
feature  dataset,  which  is  named  for  the  scale  of  the  input  feature  data 
(ranging  from  global  to  local).  ENSITE  is  constructed  using  the  fea¬ 
tures  available  at  the  GGDM’s  local  level.  However,  it  is  recognized  that 
there  may  be  a  user  workflow  in  which  data  is  available  at  the  regional 
level.  As  further  research  is  done  on  user  workflows,  plug-ins  will  be 
developed  that  have  a  variable  for  the  feature  dataset  name. 

3.  HUB_Scratch  is  a  file  geodatabase  (.gdb)  and  the  default  location  for 
storing  intermediate  data  for  products  produced  in  HUB.  A  user  is  un¬ 
likely  to  need  to  go  into  the  scratch.gdb  unless  they  are  troubleshoot¬ 
ing.  The  intermediate  contents  for  ENSITE  analytical  analyses  are 
stored  in  a  separate  geodatabase. 

4.  HUB  Analysis  is  a  geodatabase  that  contains  the  output  of  an  analy¬ 
sis  conducted  in  ENSITE  HUB  that  is  ready  for  being  ingested  in 
ENSITE  but  does  not  seem  to  fit  elsewhere  within  the  structure.  This 
folder  contains  vector  data  that  cannot  be  mapped  to  the  GGDM  stand¬ 
ard  (i.e.,  networked  datasets,  spatial  notes  of  attraction,  and  space  syn¬ 
tax). 

2.3.2  Studies  Folder 

The  Studies  Folder  contains  the  analysis  outputs  from  analytical  applica¬ 
tions.  Each  time  an  application  is  run,  a  new  folder  is  created  that  contains 
all  of  the  results.  These  folders  will  be  given  consistent  names  following 
the  structure:  Mission  Folder  Name_MGRS_TimeStamp.  (MGRS  is  the 
abbreviation  for  Military  Grid  Reference  System.)  An  example  of  a  folder 
name  would  be  “Nairobi_37MBU55_270ct20i6.”  While  including  the 
Mission  Folder  name  is  a  bit  redundant  because  all  of  the  analyses  will 
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share  the  same  first  section,  this  consistent  naming  schema  allows  for  con¬ 
sistent  sharing  of  the  data  produced.  There  are  three  elements  within  this 
folder,  which  mirror  the  inputs  and  resulting  folders  of  DataHub  (refer  to 
Figure  2),  as  listed  below: 

1.  S_MGRS_TimeStamp_Raster  contains  the  outputs  to  analytical 
analyses  that  are  raster.  * 

2.  S_MGRS_TimeStamp_Vector  contains  the  outputs  of  analytical 
analyses  that  are  GGDM  compliant.  Every  effort  should  be  made  to 
make  vector  data  GGDM  compliant. 

3.  S_MGRS_TimeStamp_Analysis  contains  non-GGDM  compliant 
vector  data  analytical  analysis  outputs. 

It  is  important  to  note  that  no  global  data  is  included  in  the  Studies  Folder. 
If  a  study  is  run  on  one  small  neighborhood  in  Dhaka,  then  only  the  data 
for  that  one  area  will  be  output.  Most  importantly,  data  produced  in 
ENSITE  HUB  and  stored  in  the  DataHub\Hub_Analysis  Folder  will  not  be 
included  in  the  Studies  Folder,  an  exclusion  that  may  be  confusing  when 
sharing  results  of  work  done  in  ENSITE  analysis  because  a  user  may  ex¬ 
pect  the  data  they  are  sharing  would  include  all  of  the  foundational  data. 
One  solution  would  be  to  create  a  “package  data”  option  within  CB_SITE 
to  gather  the  inputs  (DataHub)  and  outputs  (studies). 

2.3.3  Supporting  Folder 

The  Supporting  Folder  contains  data  to  support  analysis  in  ENSITE.  This 
folder  is  likely  the  one  that  will  expand  the  most  over  the  life  cycle  of  the 
ENSITE  research  and  development  effort.  Currently  there  are  three  sub¬ 
folders,  as  outlined  below: 

1.  Analysis_Support  contains  tables  which  are  used  in  later  analysis 
and  related  to  data  that  is  produced  in  ENSITE  HUB.  For  example,  the 
table  “MAAX_U_soils_table.csv”  relates  Army  doctrine  about  soils 
that  is  contained  in  FM  5-472  (2001)  to  the  soil  data  in  the 
MAAX_U_SoilScape  raster.  By  containing  this  linked  information 
within  a  comma-separated  values  (.csv)  file  (rather  than  code),  it  can 
be  more  easily  updated. 


*  A  prefix  of  “S”  was  added  to  these  databases  because  the  best  practice  is  to  not  start  a  geodatabase 
name  with  a  numeral. 
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2.  Basemap  contains  three  shapefiles  which  are  used  in  the  current  iter¬ 
ation  of  ENSITE  to  produce  a  basemap.  These  basemap  files  are  pro¬ 
duced  in  ENSITE  HUB.  Future  versions  of  ENSITE  should  be  able  to 
ingest  rasters,  making  this  folder  obsolete. 

3 .  Imagery  contains  imagery  basemaps . 

ENSITE  HUB  is  the  name  given  to  a  set  of  tools  developed  for  taking  the 
various  data  collected  by  ENSITE’s  analytical  tools  and  user  interface  and 
then,  becoming  the  hub  that  processes  the  collected  data  for  ingestion  by 
ENSITE  (i.e.,  organizing  the  data  collected  according  to  GGDM  stand¬ 
ards).  Specifically,  ENSITE  HUB  is  a  series  of  tools  developed  by  the 
ENSITE  team,  using  ArcGIS®  Model  Builder  and  Python®  scripts  that  pro¬ 
cess  the  data  for  GGDM  compliance.  All  the  data  produced  in  ENSITE 
HUB  is  fed  into  the  Mission  Folder  for  a  particular  mission’s  AOI.  A  user 
with  moderate  GIS  experience  is  expected  to  go  from  data  collection  to  a 
completed  Mission  Folder  in  a  few  hours. 

2.4  ArcMap  tools 

ENSITE  HUB  is  currently  a  set  of  three  tools  within  the  desktop  applica¬ 
tion  ArcMap.  These  tools  listed  below  take  data  derived  from  a  variety  of 
sources  and  compile  it  for  the  mission  folder: 

1.  Convert_CMB_to_ENSITE  is  a  tool  that  takes  raster  data  supplied 
by  the  AGC’s  CMB  as  raster  catalogs,  adds  the  appropriate  raster  pre¬ 
fix,  and  stores  the  data  as  an  ESRI  grid. 

2.  OSM_to_GGDM  is  a  tool  that  takes  data  from  OpenStreetMap® 
(OSM)  and  extracts  water,  roads,  and  railroads  into  the  GGDM  compli¬ 
ant  format. 

3.  No_Build_Culture  is  a  tool  extracts  cultural  sites  identified  as  pro¬ 
tected  sites  through  the  Hague  and  Geneva  conventions.  These  areas 
are  marked  as  no-build  in  ENSITE. 

2.5  Data  governance 

The  analysis  in  ENSITE  is  only  as  good  as  the  underlying  data.  Before  un¬ 
derlying  data  is  incorporated  into  ENSITE,  it  is  vetted  and  documented  by 
the  ENSITE  research  team.  While  initially  cumbersome,  this  process  bene¬ 
fits  the  ENSITE  program  by: 


providing  transparency  and  accountability; 


Data  Overview 
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•  ensuring  key  stakeholders  are  engaged  in  the  decision  process; 

•  ensuring  documentation  and  integration  from  the  outset;  and 

•  preventing  the  use  of  non-authoritative  data  sources  in  analysis. 

2.6  Input  data 

This  subsection  provides  the  data  governance  documentation  for  all  data 
currently  within  ENSITE. 

2.6.1  Digital  Terrain  Elevation  Data  (DTED)  Level  2 

Product  Digital  Terrain  Elevation  Data  (DTED)  is  a  product  derived  from  the  Shut- 

summary  tie  Radar  Topography  Mission  (SRTM),  done  in  conjunction  with  NASA  to 
create  the  first  near-global  set  of  land  elevations.  The  DTED  product  repre¬ 
sents  a  matrix  of  measured  elevation  posts  over  a  portion  of  the  earth's  sur¬ 
face  which  are  based  on  degree  cells.  DTED  elevations  are  in  meters, 
rounded  off  to  the  nearest  whole  meter.  DTED  Level  2  consists  of  t  arc-sec 
data  (approximately  30  m),  which  is  roughly  equivalent  to  the  contour  in¬ 
formation  contained  on  a  1:50,000  scale  topo  map.  The  SRTM  in  2000  col¬ 
lected  80%  of  the  earth’s  surface  at  this  resolution,  and  DTED-format 
datasets  are  becoming  increasingly  available.  *  The  void-filled  version  of  the 
product  (used  in  ENSITE)  contains  estimations  of  elevations  for  the  20%  of 
the  earth’s  surface  not  captured  in  the  initial  SRTM  collection.  NGA  filled 
the  voids  by  using  interpolation  algorithms  in  conjunction  with  other 
sources  of  elevation  data.  Most  voids  are  filled  with  elevation  data  from  the 
ASTER  GDEM2  (Advanced  Spaceborne  Thermal  Emission  and  Reflection 
Radiometer  Global  Digital  Elevation  Model  Version  2).f 

Product  source  NGA  via  the  CMB 

Update  Static;  last  release  2001 

frequency 

Product  Global,  with  some  holes;  for  example,  oceans  are  not  included, 

coverage 


*  More  info:  https://www.nga.mil/ProductsServices/TopographicalTerrestrial/Pages/DigitalTerrainEleva- 
tionData.aspx 

t  Source:  http://www2.jpl.nasa.gov/srtm/ 


Data  Meaning  and  Context 
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Product 

resolution 

t-arc  second,  approximately  30  meters 

Source  format 

Via  CMB,  the  format  is  raster  catalog 

Source 

projection 

WGS84 

Classification/ 

distro 

restrictions 

LIMDIS 

Use  within 

literature 

SRTM  data  is  used  widely  within  academia  and  is  considered  to  be  a  repu¬ 
table  datasource  for  elevation.  An  analysis  of  STRM  data  points  collected  by 
using  the  Global  Positioning  System  (GPS)  in  the  Catskill  Mountains  (New 
York,  USA)  and  Phuket  (Thailand).  The  analysis  found  average  differences 
in  elevation  ranging  from  7.58  ±  0.60  m  in  Phuket  and  from  4.07  ±  0.47  m 
in  Catskills  (mean  ±  S.E.M.  [standard  error  of  the  mean]).  This  range  is  sig¬ 
nificantly  better  than  a  standard  SRTM  accuracy  value  indicated  in  its  spec¬ 
ification  (i.e.,  16  m;  Gorokhovich  and  Voustianiouk  2006) 

Justification  for 

source 

The  DTED  product  is  the  most  easily  accessible  elevation  product  available 
to  our  user  base.  The  global  coverage  (and  void-filled  coverage)  makes  this 
product  globally  reliable. 

Other  products 

evaluated 

ASTER  DEM  was  evaluated.*  This  product  was  not  selected  for  use  in 
ENSITE  because  the  product’s  unique  benefits  were  unclear,  and  it  was  not 
available  through  the  CMB.  Instead,  a  product  available  through  the  CMB 
was  chosen  because  CMB  availability  allows  easy  distribution. 

Data  product 

limitations 

•  The  product’s  resolution  is  1  arc-second  and  since  some  areas  are  void- 
filled  for  location-specific  analysis,  other  more  precise  datasets  (such  as 
LIDAR)  should  be  used. 

•  The  SRTM  data  has  an  accuracy  of  16  m. 

*  https://asterweb.jpl.nasa.gov/gdem.asp 


Data  Meaning  and  Data  Overview 

Context 
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2.6.2  Oceans  and  Lakes 


Product 

summary 

Certain  analyses  in  ENSITE  require  knowing  the  location  of  water  fea¬ 
tures.  Large  water  features  including  large  lakes  and  oceans  are  not  in¬ 
cluded  in  the  OSM  database,  which  is  otherwise  relied  on  for  small  inland 
water  features.  To  rectify  this  issue,  the  Global  Lakes  and  Wetlands  Data¬ 
base  (GLWD)  from  the  World  Wildlife  Fund  and  the  OSM  Oceans  dataset 
were  merged. 

Product  source 

Developed  by  Juliana  Wilhoit 

Update 

frequency 

Static 

Product 

coverage 

Global 

Product 

resolution 

Small  -  includes  features  with  an  area  of  .01  km2. 

Source  format 

Shapefile,  polygon 

Source 

projection 

WGS84 

Classification/ 

distro 

restrictions 

None 

Necessity  of 

dataset 

Global  datasets  do  exist  for  global  water  bodies  (including  oceans).  How¬ 
ever,  these  datasets  do  not  match  the  spatial  resolution  (which  can  vary)  in 
OSM.  Currently,  a  raw  extract  of  OSM  does  not  contain  the  ocean,  as  that 
is  technically  not  a  mapped  element.  Coastlines  are  mapped,  but  oceans 
are  not.  Therefore,  to  ensure  that  there  was  contiguity  between  the  foun¬ 
dation  data  produced  using  OSM  data,  a  global  oceans  file  produced  using 
coastlines  was  used.  Furthermore,  researchers  discovered  that  some  other 
large  waterbodies  also  were  not  included  in  OSM  extracts.  As  a  result,  it 
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was  necessary  to  ensure  that  these  large  water  bodies  were  included  by  re¬ 
lying  on  the  GLWD.  A  new  dataset  was  created  to  reduce  processing  times. 

Justification  for 

source 

Ocean  Polygons:  OSM  includes  a  map  of  coastal  features,  but  not  of 
large  water  bodies.  This  dataset  includes  bodies  of  water  that  are  bounded 
by  a  coastal  area  tagged  as  “natural=coastline.”*  This  dataset  is  updated 
weekly.  However,  given  that  few  sites  are  likely  to  change,  researchers  de¬ 
termined  that  it  would  improve  the  user  experience  and  reduce  processing 

times  to  have  a  static  file. 

Global  Lakes  and  Wetlands  Database  (GLWD). 1  This  dataset  was 
developed  by  the  World  Wildlife  Fund  and  the  Center  for  Environmental 
Systems  Research,  University  of  Kassel,  Germany.  It  represents  perma¬ 
nent  open  bodies  of  water  which  are  greater  than  .01  km2.  The  dataset  was 
developed  in  2003  and  has  been  recognized  as  an  authoritative  source  of 
water  features.  The  product  may  be  limited  by  its  age,  however,  since  wa¬ 
ter  features  may  change  shape,  size,  or  existence  given  climatic  and  popu¬ 
lation  demands. 

Other  products 

evaluated 

Evaluated  global  ocean  dataset,  but  there  were  some  differences  in  the 
coastline  present  between  that  dataset  and  OSM.  Using  the  OSM  dataset 
further  ensures  that  some  large  water  features  (like  Lake  Victoria)  are  cap¬ 
tured  which  are  not  present  as  a  polygon  feature  in  the  OSM  data,  but  are 
mapped  through  their  coastlines. 

Data  product 

limitations 

The  dataset  is  static,  based  on  a  representation  of  OSM  coastlines  in  Au¬ 
gust  2016.  As  OSM  edits  occur  to  the  coastline  and  coastal  features,  there 
may  be  a  incongruity  between  these. 

*  http://openstreetmapdata.com/data/water-polygons 
t  http://www.worldwildlife.org/pages/global-lakes-and-wetlands-database 


Data  Overview 
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2.6.3  OpenStreetMap 


Product 

summary 

OSM  is  a  global  mapping  platform  using  volunteered  geographic  infor¬ 
mation  to  create  a  free  and  editable  map  of  the  world.  Started  in  2004  in 
the  UK,  OSM  has  grown  to  having  over  2  million  users  who  contribute 
data.  OSM  values  local  knowledge  and  “OpenStreetMap  emphasizes  local 
knowledge.  Contributors  use  aerial  imagery,  GPS  devices,  and  low-tech 
field  maps  to  verify  that  OSM  is  accurate  and  up  to  date.”*  Unlike  other 
projects,  the  map  is  not  viewed  as  the  primary  product;  it  is  instead  the 
underlying  data. 

Product  source 

The  Open  Street  Map  Foundation  via  MapZen  extracts.1  Due  to  limitations 
on  file  types  and  download  sizes  directly  from  the  Open  Street  Map  Foun¬ 
dation  site,  ENSITE  uses  a  mirror  server  hosted  by  MapZen.  This  server 
allows  users  to  select  the  area  they  wish  to  obtain  data  for  and  then  down¬ 
load  it  as  a  shapefile. 

Update 

frequency 

Weekly.  New  versions  of  the  OSM  database  are  published  weekly  with  a 
change  file  on  Sundays. 

Product 

coverage 

Global,  with  details  varying  on  the  location. 

Product 

resolution 

N/A 

Source  format 

Raw  data  from  OSM  is  provided  as  a  .osm  which  is  an  XML  format.  Data 
from  MapZen  are  point,  line,  and  polygon  shapefiles. 

Source 

projection 

WGS84 

Classification/ 

distro 

restrictions 

None 

*  https://www.openstreetmap.org/about 
t  https://mapzen.com/data/metro-extracts 


Data  Meaning  and  Context 
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Use  within  OSM  is  widely  becoming  a  standard  dataset  for  academics  and  practition- 
literature  ers. 

Justification  for  OSM  provides  an  invaluable  initial  step  for  assessing  the  urban  environ- 
source  ment  globally  at  the  UNCLASS  level.  The  dataset  is  not  comprehensive, 

and  there  are  differences  in  quality  depending  on  location.  However,  the 
depth  of  data,  the  ease  of  use,  and  its  growing  adoption  by  the  DoD  and  ac¬ 
ademic  communities  demonstrates  its  weight.  For  example,  OSM  is  the 
base  of  the  NGA  project  MapEdit.  MapEdit  builds  on  a  snapshot  of  the 
OSM  database  from  2016  and  allows  the  Intel  Community  to  add  data  for 
areas  of  interest.  These  edits  are  published  to  the  MapEdit  database  and 
not  viewable  by  those  outside  the  DoD.  Additionally,  MapEdit  data  can  be 
exported  in  accordance  with  the  DoD  Standard  Schema  called  the  Topo¬ 
graphic  Data  Store  (TDS).  For  many  areas  of  the  world,  local  mapping  ef¬ 
forts  have  added  additional  data  since  the  initial  OSM  snapshot  was  taken. 
Unfortunately,  this  additional  data  makes  it  seem  that  all-too-important 
information  about  the  military  operational  environment  is  missing  in 
OSM. 


detail  including  additional  streets 
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Other  products  Wikimapia  was  pursued  as  an  additional  data  source.*  Unlike  OSM, 
evaluated  Wikimapia  perceives  the  main  output  to  be  the  map  itself,  which  results  in 
a  more  difficult  experience  to  download  data.  Additionally,  Wikimapia 
does  not  have  as  large  a  user  community,  meaning  that  its  data  are  more 
sparse. 

Data  product  •  Accuracy-  As  the  means  of  data  collection  differ  (handheld  GPS,  satellite 
limitations  imagery,  “Walking  Papers” f),  the  spatial  locations  of  sites  may  differ 

slightly  from  surveyed  locations  and  as  a  result  “each  contribution  follows 
its  own  level  of  detail  standards”  (Touya  2012).  A  study  done  of  OSM  in 
2010  in  the  UK  that  matched  OSM  data  and  the  government  ordinance 
survey,  found  a  6  m  difference  between  OSM-identified  locations  and  the 
surveyed  locations  (Hacklay  2010).  A  study  of  OSM  conducted  in  France 
found  greater  issues  with  the  quality  of  the  data  (Girres  and  Touya  2010). 
Another  study  looking  at  building  footprints  in  Munich,  Germany,  shows 
“that  OSM  footprint  data  in  Munich  have  a  high  completeness  and  seman¬ 
tic  accuracy"  (Hongchao  et  al.  2014). 

•  Non-Authoritative  Source  -  While  OSM  is  considered  to  be  an  invaluable 
source  for  the  ENSITE  team,  it  is  not  considered  an  authoritative  data 
source  by  the  DoD.  Because  of  this,  all  OSM  data  for  ENSITE  use  is  con¬ 
verted  so  that  it  follows  the  GGDM,  which  is  the  Army  standard.  This  con¬ 
version  allows  future  swap-in  of  an  authoritative  data  source  without 
having  to  change  ENSITE  analysis  procedures. 


2.6.4  SoilScape 


)ver- 

vicvv 

Product 

The  SoilScape  Unified  Soils  Classification  System  Layer  (Usoils)  provides 

summary 

information  on  soil  type  based  on  the  Unified  Soils  Classification  System 

cd 

(USCS),  which  is  an  engineering  properties-based  system.  Attribution  in¬ 

cd 

cludes  a  two-letter  soils  identifier  and  a  brief  text  description  of  the  soil 

H 

type. 

*  http://wikimapia.org/ 

t  Walking  Papers  provides  the  option  of  an  A4-size  printout  of  an  OSM  map  and  then,  it  allows  user  an¬ 
notations  to  be  scanned  so  that  new  features  can  be  added  to  OSM.  (http://wiki.open- 
streetmap.org/wiki/Walking_Papers). 
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Product  source  NGAviaCMB 


Update 

frequency 

Static 

Product 

Near  global 

coverage 

Product 

resolution 

30  m,  with  a  90-m  minimum  mapping  unit  (MMU) 

Source  format 

Raster 

Source 

projection 

WGS84 

Usage 

limitations 

LIM  DIS//  FOUO 

Classification/ 

distro 

restrictions 

None 

Use  within 

literature 

No  articles  citing  this  data  source  were  able  to  be  found.  This  is  due  in  part 
to  the  fact  that  this  data  source  originates  from  within  the  intelligence 
community. 

Justification 

for  source 

This  soil  dataset  is  considered  to  be  the  foundation  dataset  by  NGA.  This 
means  that  other  NGA  products  are  built  off  this  dataset. 

Other  products  None,  because  this  product  is  considered  to  be  the  authoritative  source 
evaluated  and  it  has  near-global  coverage. 

Data  product  One  of  the  limitations  of  the  product  is  that  there  is  limited  information 
limitations  available  on  the  data  source. 


Data  Overview 
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2.6.5  UNESCO 


Product 

summary 

This  dataset  is  from  the  United  Nations  Educational,  Scientific  and  Cul¬ 
tural  Organization  (UNESCO)  World  Heritage  program  and  contains  the 
coordinates  for  these  sites.  UNESCO  sites  are  selected  as  having  global 
significance  to  culture,  science,  or  history.  UNESCO  World  Heritage  sites 
are  protected  by  international  treaty.*  There  are  currently  1,052  sites 
globally.  This  list  includes  the  three  categories  of  sites,  as  follows:  cul¬ 
tural,  natural,  and  mixed. 

Product  source 

UNESCO  World  Heritage  Program1 

Update 

frequency 

Annual 

Product 

coverage 

Global 

Product 

resolution 

N/A;  it  is  the  center  of  the  site 

Source  format 

.csv  with  coordinates  for  sites 

Source 

projection 

WGS84 

Classification/ 

distro 

restrictions 

None 

*  Source:  http://whc.unesco.org/en/criteria/. 
t  http://whc.unesco.org/en/syndication 
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Use  within 

literature 

The  UNESCO  World  Heritage  Sites  are  a  global  dataset.  This  dataset  is 
used  both  for  research  and  policy  making. 

Justification 

for  source 

The  UNESCO  World  Heritage  sites  list  obtained  directly  from  the  UN  is 

considered  to  be  the  authoritative  source  for  the  location  of  these  sites. 

Other  products 

evaluated 

None.  This  is  the  authoritative  data  source. 

Data  product 

limitations 

UNESCO  provides  a  center  point  for  a  feature  and  the  area  of  the  site  in 
hectares.  No  boundaries  of  sites  are  provided.  A  2012  release  of  the 

UNESCO  data  which  included  boundaries  indicated  that  boundaries  were 

obtained  from  the  WDPA,*  which  is  also  used  in  ENSITE  in  conjunction 

with  this  data. 

VISNAV  land  use/land  cover 


Product 

summary 

NGA  has  several  land  use/land  cover  (LULC)  products  under  the  Visual 
Navigation  (VISNAV)  program  since  2010. 1  Each  product  supports  a  vari¬ 
ety  of  applications  such  as  broad  area  search,  cartographic  vegetation 
mapping,  vehicle  mobility  modeling,  engineering  planning,  and  humani¬ 
tarian  disaster  response. 

The  basic  land  cover  product  (LC)  was  developed  using  LandSat  and  has 
a  resolution  of  30  m.  The  dataset  has  12  LULC  classes. 

Product  source 

NGA  via  the  CMB 

Update 

frequency 

2015-2016.  Static,  although  the  research  project  is  ongoing,  producing 
higher-fidelity  data. 

*  http://whc.unesco.org/en/news/853 

t  https://www.arcgis. com/home/item. html?id=bbeb2585b4704b67bf81dl744acbc55d 
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Product  Global  with  the  exception  of  continental  United  States  (CONUS), 

coverage  _ 


Product 

resolution 

30  m,  with  a  900-m2  MMU 

Source  format 

Raster 

Source 

projection 

WGS84 

Classification/ 

distro 

restrictions 

None 

Use  within 

literature 

No  examples  of  data  used  in  literature  could  be  found,  as  this  is  a  founda¬ 
tion  dataset  used  in  military  work. 

Justification  for 

source 

The  VISNAV  LULC  is  a  DoD-identified  foundation  layer  for  geospatial 
analysis.  That  means  that  this  layer  is  used  in  the  development  of  other 
products,  and  it  is  a  data  source  with  which  the  warfighter  has  familiarity 
and  which  may  be  familiar  to  other  projects. 

Other  products 

evaluated 

There  are  additional  products  in  this  family. 

VISNAV  high-definition  (HD)  was  derived  in  2015-2016  from  a  single 
RapidEye  imager,  5m  resolution,  and  has  a  900-m2  MMU  (36  pixels). 
VISNAV  HD  was  produced  over  17  AOIs:  Afghanistan,  Lebanon,  Djibouti, 
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Nigeria,  Eretria,  North  Korea,  Gaza  Strip,  Pakistan,  Iran,  Somalia,  Iraq, 
Syria,  Israel,  West  Bank,  Jordan,  Yemen,  and  Kenya. 

'  7 

Data  product 

limitations 

None 

2.6.7  World  Database  on  Protected  Areas 


£ 

0) 


0) 

> 

O 

■M 

Q 


Product  The  2.6.7  World  Database  on  Protected  Areas  (WDPA)  is  a  corn- 

summary  prehensive  datasource  of  protected  areas  which  is  updated  monthly.  It  is 

the  most  comprehensive  global  dataset  of  marine  and  terrestrial  pro¬ 
tected  areas-including  spatial  data  (polygon  boundaries  and  points)  and 
tabular  information.  The  WDPA  is  a  joint  project  between  the  United 
Nations  Environment  Programme  (UNEP)  and  the  International  Union 
for  Conservation  of  Nature  (IUCN).  The  WDPA  was  established  in  1981. 
The  WDPA  data  structure  and  protocols  were  updated  in  2015  to  incor¬ 
porate  protected  lands  information  from  additional  parities  including 
private  land  conservation  groups,  local  communities,  and  indigenous 
peoples.  (Juffe-Bignoli  et  al.  2016). 

Product  source  UNEP’s  World  Conservation  Monitoring  Centre,  via  the  Protected  Planet 
site. * 

Update  Monthly* 

frequency 


*  https://www.protectedplanet.net/ 

t  https://www.protectedplanet.net/c/frequency-of-update-of-the-wdpa 
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Product 

coverage 

Global 

Product 

resolution 

N/A;  data  is  polygon/point.  Resolutions  vary  based  on  site. 

Source  format 

Shapefile—  polygon  and  point 

Source 

projection 

The  WDPA  is  supplied  in  a  geographic  co-ordinate  system:  WGS84.  The 
Mollweide  projection  is  used  to  calculate  the  “GIS  Area”  (GIS_AREA) 
and  “marine  GIS  area”  (GIS_M_AREA)  fields  in  the  WDPA  attribute  ta¬ 
ble  (Juffe-Bignoli  et  al.  2016,  29). 

Classification/ 

distro 

restrictions 

None 

Use  within 

literature 

The  reach  of  the  WDPA  is  further  enhanced  by  services  developed  by 
other  parties,  such  as  the  Global  Forest  Watch  and  the  Digital  Observa¬ 
tory  for  Protected  Areas/  which  provide  decision  makers  with  access  to 
monitoring  and  alert  systems  that  allow  whole  landscapes  to  be  man¬ 
aged  better. 

Justification  for 

source 

This  data  was  selected  because  of  its  global  coverage,  monthly  updates, 
and  data  governance  structure. 

Other  products 

evaluated 

Evaluated  OSM  data  and  found  that  features  present  in  both  satellite  im¬ 
agery  and  WDPA  were  missing.  As  a  result,  WDPA  was  selected.  Addi¬ 
tionally,  as  a  United  Nations  (UN)  program,  the  WDPA  contains  the 
officially  recognized  boundaries  for  UNESCO  environmental  sites. 

Data  product 

limitations 

One  limitation  of  the  product  is  that  the  data  is  collected  from  a  variety 
of  sources.  As  of  March  2017,  the  data  in  the  WDPA  was  derived  from 
over  500  sources.  The  user  guide  for  the  data  (Juffe-Bignoli  et  al. 

2016,  31)  states  “How  data  providers  have  digitized  the  boundaries  of  a 

*  http://www.globa  lforestwatch.org/ 

t  http://dopa.irc.ec.europa.eu/en 
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protected  area,  at  what  scale,  which  references  they  have  used  to  map  ar¬ 
eas  in  relation  to  administrative  boundaries,  coastline  maps  and/or 
landscape  features  (e.g.,  rivers  or  lakes)  will  have  a  great  influence  in  the 
accuracy  of  the  data.”  Additionally,  while  doing  a  visual  test  of  the  data, 
two  areas  appeared  to  be  located  in  the  wrong  place. 
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3  Step-by-Step  Instructions  for  ENSUE  HUB 

The  steps  provided  in  this  chapter  walk  a  user  through  the  process  of  ac¬ 
quiring  data  and  processing  it  through  ENSITE  HUB. 

3.1  Step  1:  Acquire  the  necessary  tools 

ENSITE  HUB  assumes  that  data  to  be  processed  is  located  within  a  folder 
called  C:\ENSITE\Data.  Using  hat  particular  folder  location  ensures  that 
the  database  is  able  to  be  called  similarly  across  all  computers.  Users 
should  make  that  folder  if  it  does  not  exist  on  their  computer.  If  desired, 
users  can  create  the  folder  in  any  other  location;  however,  if  that  option  is 
used  the  file  path  for  each  tool  in  HUB  would  then  need  to  be  changed  ac¬ 
cordingly. 

1.  Download  the  ENSITE  Hub  toolbox  and  Base_Data.  This  toolbox  is 
hosted  through  the  Di2E  program  (Di2e.net).  Access  to  this  page  is 
available  to  any  person  with  a  common  access  card  (CAC)  and  can  be 
found  by  searching  for  ENSITE.  Alternatively,  access  to  the  page  can  be 
requested  by  emailing  Juhana.M.Wilhoit(wUSACE.Army.mil.  This 
site’s  pages  include  additional  guides  and  videos  of  the  ENSITE  HUB 
tools. 

2.  Once  its  downloaded,  unzip  the  base  data  folder  and  place  it  in  the 
C:\ENSITE\Data  folder. 

A  few  folders  may  need  to  be  created  on  the  user’s  computer.  The  HUB’s 
processes  will  be  much  easier  if  the  following  locations  are  used: 

1.  Base_Data  with  the  path  of:  C:\ENSITE\Data\Base_Data 

2.  The  HUB  Toolbox  should  be  placed  in  C:\ENSITE\Toolboxes 

3.  Create  a  desktop  folder  for  downloading  and  unzipping  all  required 
data. 

3.2  Step  2:  Obtain  the  required  data 

To  acquire  the  data  necessary  to  run  basic  ENSITE  analyses,  users  must 
obtain  various  data  from  AGC’s  CMB,  OSM,  and  Protected  Planet.  Below 
are  the  steps  for  how  to  collect  this  data  for  each  AOI. 
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3.2.1  Elevation,  soil,  and  land  cover  data  from  CMB 

1.  Navigate  to  CMB:  https://agcwfs.agc.armv.mil/CMB  Online 

a.  Log  in  with  your  CAC  and  then  choose  email  certificate  option. 

b.  A  CMB  Online  help  screen  will  pop  up,  which  can  be  navigated  to 
get  more  information.  Choose  "X"  to  close  the  help  screen  when 
done. 

2.  Create  and  then  add  an  AOI  to  the  cart  by  doing  the  following: 

a.  Locate  an  area  by  going  to  Tools  >  Create  AOIs  >  Search  Gazetteer. 

b.  **NOTE  that  by  default,  ENSITE  selects  data  from  within  15  km  of 
the  city  center. 

c.  An  AOI  can  be  created  manually  by  drawing  it,  using  one  of  the 
“create  AOI”  tools  at  left  side  of  the  screen. 

3.  Select  the  base  data  necessary  for  ENSITE.  On  the  left  side  of  the 

screen,  navigate  through  the  product  catalog  to  select  the  datasets 

listed  below.  Right  click  on  each  and  select  “ADD  SELECTED  ITEMS 

TO  CART.” 

a.  DTED  SRTM  >  CMB_ELV_SRTMVF 2 .  This  is  Space  Shuttle  Ra¬ 
dar  Topography  Mission  Level  1,  void-filled  at  a  l-arc  second  reso¬ 
lution.  (l-arc  second  ~  30  m). 

b.  LandCover  Datasets  >  LandCover__VISNAV 

c.  LandCover  Datasets  >  MAXX_SOILSCAPE_TIFFs 

d.  Water  Resources  Database  >  WRDB_Vector 

Figure  4  provides  a  screenshot  with  the  appropriate  items  selected. 
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Figure  4.  Screenshot  of  CMB  product  catalog  with  appropriated  boxes  checked. 

~  C  Product  Catalog 

►  CD  Buckeye  Mosaic  Tiles 

►  CD  Elevation  Datasets 
■V  fe>  DTED  SRTM 

□  □  CMB_ELV_DTEDO 

□  □  CM  B_ELV_DTED  1 

□  □  CMB_ELV_DTED2 

□  □  CMB_ELV_SRTM1 

□  □  CMB_ELV_SRTM2 

□  □  CMB_ELV_SRTMVF1 
ST  □  CMB_ELV_SRTMVF2 

►  C  CIB 

F  C  CADRG 

►  Cl  ECRG 

w  C  Land  Cover  Datasets 

□  □  LandCover_GeoCover 
BT  □  LandCover_VISNAV 
BT  □  MAAX_SoilScape_Tiffs 

F  P  ]  GeoPDF  Datasets 
F  Cl  GGDM  Vector  Datasets 
F  C  MAAX  Vector  Datasets 
F  C  VMAP  Vector  Datasets 
F  C  Army  Installation  Datasets 
F  C  Inland  Electronic  Navigation  Charts 
w  C  Water  Resources  Database 
BT  □  WRDB_Vector 

□  □  WRDB_KML 


4.  Proceed  to  checkout  by  following  the  steps  below.  Figure  5  provides  a 

screenshot  of  the  checkout. 

a.  Navigate  to  Cart  (top  bar). 

b.  Review  the  order  and  see  if  it  exceeds  40  GB.  If  it  does,  the  order 
will  be  shipped  via  the  mail.  If  the  data  is  needed  immediately,  ex¬ 
amine  which  files  are  the  largest,  remove  them,  and  then  complete 
two  (or  more)  orders. 

c.  Select  the  “Shipping  Info”  tab  at  the  top  of  the  page  and  type  your 
shipment  information.  This  information  is  required  even  if  you  are 
downloading  data. 

d.  Select  the  “Order  Config”  tab  and  accept  the  defaults. 

e.  Select  “Submit  Order  for  Download.” 
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Figure  5.  Screenshot  of  CMB  cart. 
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scroll  over  to  see  the  total  file  size  for  the  dataset 


5.  Download  the  data. 

a.  Users  will  receive  an  email  with  the  subject  line  “CMB  Download  is 
ready.”  Follow  the  link  in  the  email  to  download  requested  data. 

b.  Extract  the  data  to  the  computer  folder  previously  set  up  for  all 
data.  This  location  can  be  any  folder  on  your  computer. 

3.2.2  Road  data  from  Open  Street  Map 

OSM  data  is  a  free  and  open-source  dataset  to  which  volunteers  contribute 
data.  The  dataset  is  by  no  means  comprehensive,  but  it  has  determined 
that  it  is  sufficient  for  our  needs  and  it  is  the  best  option  that  we  have. 
There  are  many  options  for  downloads  of  OSM  data.  For  the  moment, 
ENSITE  is  relying  on  a  service  which  will  easily  extract  the  data  for  your 
needs,  as  described  in  the  steps  that  follow. 

l.  Navigate  to:  iittps://mapzen.com/data/metro-extracts  and  search  for  the  desired 
city.  There  may  be  two  options  for  a  city  with  a  headings  of  "popular 
extracts  ready  for  download  now"  or  "to  make  a  custom  extract."  If  the 
desired  city  shows  up  under  "popular  extracts  ready  for  download," 
great!  Select  it.  And  on  the  following  page  select  to  download 
SHAPEFILE  in  the  OSM2PGSQL  type.  The  pink  box  represents  the 
area  to  be  examined,  so  make  sure  the  extent  of  the  pink  box  includes 
the  entire  area  to  be  examined.  Figure  6  is  a  screenshot  of  this  selection 
process  in  OSM. 
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2.  If  there  is  not  a  ready  extract  available  (indicated  by  a  header 
of  “create  custom  extract”),  drag  the  gray  box  over  the  map  to  the 
extent  desired.  Options  of  different  levels  may  be  given  for  an  area, 
such  as  “local”  or  “regional.”  It  does  not  matter  which  level  is  selected. 
Next,  select  the  “GET  EXTRACT”  button.  If  that  button  is  greyed  out, 
the  selected  area  is  too  large  and  multiple  smaller  requests  will  need  to 
be  submitted.  To  do  that,  simple  change  the  selection  box  to  be  smaller, 
until  the  button  is  not  greyed  out.  Make  a  mental  note  of  the  extents  of 
the  box  (such  as  a  city  or  feature  bounding  each  city)  and  use  that  mark 
to  begin  an  area  for  subsequent  extracts. 

a.  Next,  the  user  will  be  directed  to  Git  Hub,  where  sign-in  is  needed 
to  complete  the  custom  extract  process.  Thus  it  will  be  necessary  to 
create  an  account  if  one  does  not  already  exist.  It  may  take  30-60 
minutes  for  the  extract  to  be  ready.  Git  Hub  will  send  an  email 
when  it  is  done.  Or  you  can  refresh  the  page 

(https://mapzen.com/data/metro-extracts/vour-extracts/).  Figure  7  is  a  screenshot 
of  the  Git  Hub  data  download  page. 

b.  Download  and  extract  the  data  to  the  location  you  created. 
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Figure  7.  Screenshot  of  Git  Hub  to  extract  OSM  datasets. 
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3.2.3  Cultural  and  heritage  sites  data  from  Protected  Planet 

1.  Navigate  to  Protected  Planet:  https://www.protectedpianet.net/.  Protected 
Planet  is  a  program  run  by  UNEP,  and  it  contains  data  on  natural  areas 
around  the  world.  The  dataset  is  updated  each  month. 

2.  Search  for  the  COUNTRY  that  the  AOI  is  located  in  by  selecting  the 
magnifying  glass. 

3.  This  selection  will  bring  up  a  page  for  the  location  being  sought.  Select 
the  (generally  first)  option  for  your  COUNTRY.  Select  the  “Download 
this  dataset”  and  select  “.shp,”  as  illustrated  in  Figure  8.  This  selection 
should  result  in  downloads  of  both  polygon  and  point  shapefiles. 

4.  Extract  the  WDPA  Dataset  point  and  polygon  shapefiles  files  to  the 
folder  created  for  storing  data. 

Figure  8.  Screenshot  of  Protected  Planet’s  download  process. 


ERDC/CERL  SR-17-14 


32 


3.3  Step  3:  Create  the  Mission  Folder  in  ArcMap 

1.  First,  connect  to  the  toolbox  (located  in  C:\ENSITE\Toolboxes).  For 
more  information  on  adding  toolboxes  visit  the  ArcGIS  website.* 

2.  Then,  the  first  step  in  populating  a  database  is  to  create  the  Mission 
Folder.  In  the  HUB  toolbox,  double  click  the  model  “Create_Mis- 
sion_Folder”. 

3.  The  user  inputs  are  the  Mission  Name  and  the  start  file  locations,  as  il¬ 
lustrated  in  Figure  9.  This  assumes  that  the  base  data  pulled  from  the 
s-drive  is  located  in  C:\ENSITE\Data\Base_Data,  and  that  there  is  al¬ 
ready  a  data  folder  located  in  C:\ENSITE\Data.  If  the  paths  do  not  al¬ 
ready  exist,  they  will  need  to  be  created  or  updated. 

Figure  9.  Screenshot  of  user  entering  the  mission  name  in  the  Mission  Folder. 


3.4  Step  4:  Load  data  into  the  geodatabase 

Once  the  data  is  downloaded  and  the  Mission  Folder  created,  it  is  time  to 
transform  the  data  to  look  like  GGDM  data. 

3.4.1  CMB  data 

1.  After  receiving  the  email  with  the  link  to  download  the  data  from  CMB, 
choose  >  Download  >  Extract 

2.  In  ArcMap,  run  the  Convert_CMB_To_ENSITE  tool  from  the 
ENSITE  HUB  toolbox. 


*  http://pro.arcgis.com/en/pro-app/help/projects/connect-to-a-toolbox.htm 
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3.  For  the  input  called  Raster  Catalog,  select  the  location  of  the  raster  cat¬ 
alog  from  the  CBM  download. 

The  above  steps  will  need  to  be  repeated  for  every  dataset  downloaded 
from  CBM. 


3.4.2  OSM  data 

Select  the  “Load_OSM_to_ggdm”  tool  from  the  “OSM_to_GGDM”  tool- 
set.  Additionally,  the  tool  relies  on  water  body  data  from  the  World  Wild¬ 
life  Fund  (WWF)  and  a  separate  OSM  extract  to  get  additional  water 
information.  The  Oceans_Lakes_Merged.shp  is  located  in  the  ENSITE 
base  data  folder.  This  data  uses  the  OSM  lines  and  polygons  which  were 
downloaded  and  extracted  during  an  earlier  step.  Figure  10  provides  a 
screenshot  of  this  tool. 


Figure  10.  Screenshot  of  the  ENSITE  HUB  tool  "load  osm  to  ggdm”. 


l©$d_05m_to_ggd  m 

Ode  error  end  warning  icons  for  more  ^formation 

OSNUnt _ 

D:VSIS_D«taV5SMy<awaiVionoWu_hawai.osm2>pgsql-* *hapefiesVKnoWu_hawa«_osm_lne.dTp 
OSH  polygon 

D:V3IS_PataVDSMtiawailhonokiu_hawai.osm2pgsd-^a()efieslhonoluiu_haw«_osmjM<ygon.sh{> 
Mission  Folder 

D:\ENSITE\Data\Testl 
{^Oceans  _lakes_Merged.  shp 

D:\ENSITE\Data\BaseJData\GIS\Oceans_Lakes_Mergad.shp 


0  * 


& 

g 

l§§ 


3.4.3  No-build  cultural  areas  data 

Use  the  “Create  No  Build  Areas”  within  the  “No_Build_Culture”  toolset  to 
extract  cultural  buffers  and  then  place  a  100  m  buffer  around  them.  Bul¬ 
leted  below  are  the  inputs  with  descriptions  of  their  purpose.  Figure  11 
provides  a  screenshot  sample  of  entering  the  inputs. 

•  OSM  Point/  Line/  Polygon.  Link  to  the  location  on  your  computer 
for  the  point/  line/  polygon  shapefiles. 

•  Mission  Folder  is  the  new  folder  created  during  this  process  in  Step  1 
(section  3.1). 

•  UNESCO  sites  do  not  need  to  be  mapped  to.  UNESCO  sites’  infor¬ 
mation  is  located  in  the  base  data  on  your  computer  and  should  be  fine. 
This  parameter  is  noted  here  only  in  the  event  that  the  ENSITE  folder 
is  not  located  on  the  user’s  C-drive. 
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•  Protected  Planet.  Provide  the  file  path  to  both  the  point  and  polygon 
shapefiles  for  the  Protected  Planet  data. 

Figure  11.  Screenshot  of  inputs  to  the  “No_Build_Culture”  ENSUE  HUB  tool. 

♦  OSM  Polygon 

I 

%  OSM  Line 

♦  OSM  Pant 


UNESCO JZOM.shp 

C:\ENSITE\Data\Base_Data\GIS\UNESCO_2014.shp 

♦  Protected  Plant  Polygon  Shp 


♦  Protected  Planet  Pont  Shp 


ERDC/CERL  SR-17-14 


35 


4  Conclusion  and  Next  Steps 

The  ENSITE  project  is  novel,  both  as  a  product  and  process,  for  both  the 
U.S.  Army  and  the  broader  GIS  defense  solutions  community.  As  of  July 
2017,  ENSITE  had  developed  eight  versions  of  the  core  software,  con¬ 
ducted  over  a  dozen  user  engagement  sessions,  and  partnered  with  two 
other  major  Army  software  development  programs  for  deployed  forces. 
The  ENSITE  HUB  tool  was  developed  initially  as  a  simple  tool  to  assist  in 
speeding  up  some  daily  workflow  tasks  but  then  emerged  as  a  core  part  of 
the  ENSITE  product.  The  ENSITE  team  has  produced  two  major  versions 
of  the  HUB  tool,  conducted  a  user  jury,  and  now  has  a  clear  process  for 
data  governance. 

Feedback  on  ENSITE  HUB  was  received  February  2017,  when  the  ENSITE 
data  management  team  hosted  a  user  jury,  comprised  of  researchers  at  the 
Construction  Engineering  Research  Laboratory,  to  receive  feedback  on 
ENSITE  HUB’s  tools  and  workflow.  The  jury  was  comprised  of  seven  par¬ 
ticipants  ranging  from  an  undergraduate  student  to  a  PhD  holding  re¬ 
searcher.  Most  of  the  jury  members  had  minimal  GIS  background,  and 
none  had  engaged  with  the  ENSITE  HUB  tools  prior  to  the  event.  The  user 
jury  event  asked  participants  to  go  through  the  process  of  creating  a  Mis¬ 
sion  Folder  for  the  area  of  Nairobi,  Kenya.  The  jury  users  worked  through 
the  process,  from  acquiring  the  data  to  processing  it  into  the  Mission 
Folder. 

These  first-time  users  provided  invaluable  feedback  to  shape  the  future  di¬ 
rection  of  the  product.  Overall,  the  feedback  for  improvement  from  the  us¬ 
ers  was  minor  and  related  to  clarifying  language.  Watching  users  use  the 
ENSITE  HUB  tool  showed  that  how  users  were  not  reading  directions  or 
utilizing  all  of  the  tools  available  to  them  (such  as  watching  videos  on  the 
process).  Furthermore,  through  watching  users  interact  with  the  software 
and  process,  ENSITE  researchers  saw  that  the  workflow  was  cumbersome. 
All  users  commented  that  it  would  have  been  easy  to  choose  not  to  run  the 
ENSITE  HUB  tool,  either  because  they  didn’t  value  it  or  because  they 
didn’t  see  the  need. 

Based  on  that  observation,  the  ENSITE  research  team  determined  that  a 
new  vision  of  ENSITE  HUB  was  necessary.  During  the  remaining  years  on 
the  project,  ENSITE  HUB  will  rely  less  on  users  acquiring  necessary  data 
by  collecting  it  from  various  websites.  Instead,  ENSITE  HUB  may  become 
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a  server  type  of  solution,  where  the  required  data  is  stored  for  the  entire 
globe  (with  updates  maintained  as  well).  Figure  12  is  an  initial  mock-up  of 
the  potential  future  ENSITE  HUB,  where  a  user  simply  draws  a  box  on  a 
screen  to  select  an  AOI  and  from  there,  the  Mission  Folder  is  created  with¬ 
out  further  user  effort  or  input. 

Thus,  significant  work  remains  to  transform  ENSITE  HUB  from  a  cumber¬ 
some  process  to  a  more  streamlined,  automated  process.  Continued 
ENSITE  research  efforts  will  test  the  feasibility  of  future  developments  in 
the  ENSITE  HUB  automated  process. 

Figure  12.  Mockup  of  potential  start  page  for  ENSITE  HUB  Version  2.0. 

Welcome  to  ENSITE  HUB 

ENSITE  HUB  is  your  one-stop  shop  for  developing  your  mission  folder. 

Ready  to  start?  Just  draw  a  polygon  over  the  area  you  want  to  work. 

P  +  l*'  /  ■ ' 


MS 
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